home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11211 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.4 KB
  1. Path: azure.dstc.edu.au!crawley
  2. From: crawley@dstc.edu.au (Stephen Crawley)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: C/C++ knocks the crap out of Ada
  5. Date: 13 Mar 1996 06:01:37 GMT
  6. Organization: CRC for Distributed Systems Technology
  7. Message-ID: <4i5oc1$ee8@azure.dstc.edu.au>
  8. References: <JSA.96Feb16135027@organon.com> <4hhred$1rn@sun152.spd.dsccc.com> <4i19mg$vkt@azure.dstc.edu.au> <4i4cf2$crm@sun152.spd.dsccc.com>
  9. Reply-To: crawley@dstc.edu.au
  10. NNTP-Posting-Host: foxtail.dstc.edu.au
  11.  
  12. In article <4i4cf2$crm@sun152.spd.dsccc.com>,
  13. Kevin Cline <kcline@sun152.spd.dsccc.com> wrote:
  14. >In article <4i19mg$vkt@azure.dstc.edu.au>,
  15. >Stephen Crawley <crawley@dstc.edu.au> wrote:
  16. > >This is not a problem that can be blamed on the Ada language but on
  17. > >  a) late development of standardised Ada bindings and
  18. > >  b) unwillingness by Verdix to implement the standard when it 
  19. > >     arrived, maybe as an indirect consequence of a)
  20. >
  21. >I wasn't trying to place blame; I'm trying to explain to Ada advocates
  22. >why most PC and UNIX software developers were (and still are)
  23. >uninterested in Ada, despite the well-known pitfalls in C development.
  24. >
  25. >In fact there were several serious flaws in the Ada-83 language
  26. >that made development of hosted applications in Ada-83 more difficult
  27. >than developing them in C or C++.
  28.  
  29. I can accept that your Ada-83 compiler had flaws that made development
  30. difficult for you.  But you'll need to provide some specifics before I
  31. can accept that Ada language flaws made development in Ada more
  32. difficult than in C / C++.  [Note: language flaws ... not compiler
  33. flaws.]
  34.  
  35. > >It is unreasonable to expect any validation suite to find all cases
  36. > >where a compiler diverges from the standard.  Arguably the ACVC tests
  37. > >should be / have been more extensive though.
  38. >
  39. >The existence of the validation process is often given as an
  40. >advantage of Ada over C and C++.  Now you are admitting that
  41. >validation is a political process, and has almost no technical value.
  42.  
  43. No I am not "admitting" anything of the sort.  I'm simply restating
  44. the well known fact that testing proves the presence of bugs not the
  45. absence of bugs.  Please don't put words into my mouth.
  46.  
  47. > >With the arrival GNAT, the commercial vendors have some real
  48. > >competition in terms of compiler quality.  If they don't come up to
  49. > >scratch, they are liable to lose market share.
  50. >
  51. >There never seemed to be enough licensees to allow the compiler
  52. >vendors to create a decent product in the early 90's; has this
  53. >changed, or will GNAT be the only game in town?  That's not
  54. >necessarily bad; I like public-domain software.  
  55.  
  56. I don't know if it has changed.  But if it hasn't changed, then we can
  57. expect to see the exit of some commercial vendors from the Ada
  58. compiler marketplace.  [I agree with you that this is not necessarily
  59. a bad thing.]  
  60.  
  61. On the other hand, the advent of GNAT seems to have generated a lot
  62. of interest in Ada that may have the effect of increasing the volume
  63. of commercial sales.
  64.  
  65. >>There are emerging public domain X and MOTIF bindings for Ada that
  66. >>(assuming they are available with GNAT sometime soon) are IMO likely
  67. >>to become defacto standards.
  68. >
  69. >Emerging? Available soon?  
  70.  
  71. Read this:
  72.  
  73.  http://lglwww.epfl.ch/Ada/Resources/Bindings.html
  74.  
  75. looking for the material on Ada X11 / MOTIF bindings.
  76.  
  77. I'm afraid most of your opinions on the usefulness of Ada are based on
  78. outdated information.
  79.  
  80. >>Yes.  But given recent (though belated) standardisation activities and
  81. >>the increasing influence of the GNU / FSF movement in the Ada
  82. >>community, one would hope that this should be less of a problem in the
  83. >>future.
  84. >
  85. >I agree; within five years I predict the DoD mandate will be quietly
  86. >repealed (or largely ignored) and Ada will go the way of APL.
  87.  
  88. I disagree that you agree with me :-).
  89.  
  90. While I wouldn't be surprised if the Ada Mandate was dropped (I think
  91. it has outlived its usefulness), I think that Ada is starting to take
  92. off ... largely as a consequence of GNAT and the GNU / FSF influence,
  93. and of the increasing number of University courses that use Ada as the
  94. primary teaching language.
  95.  
  96. >>Note that the CORBA standard language bindings for Ada are expected to be
  97. >>formally approved at the OMG board meeting that happens on March 20th (for
  98. >>memory)
  99. >
  100. >I hope they are better than the abominable C++ bindings.
  101.  
  102. You old grizzle pot, you :-)
  103.  
  104. Seriously, if you want to find out, look at this:
  105.  
  106.   http://conf4.darpa.mil/corba-ada/95-5-16.V1-1.ps
  107.  
  108. -- Steve
  109.  
  110.